home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-meyer-rip-analysis-00.txt < prev    next >
Encoding:
Text File  |  1993-07-08  |  6.8 KB  |  224 lines
  1.  
  2.  
  3. Network Working Group                                         G.M. Meyer
  4. Internet Draft                                            Spider Systems
  5. Expires Dec 25, 1993                                            Jun 1993
  6.  
  7.  
  8.           Routing over Demand Circuits - RIP Protocol Analysis
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This memo is being distributed to members of the Internet community
  14.    in order to solicit their reactions to the proposals contained in it.
  15.  
  16.    This document is an Internet Draft.  Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups.  Note that other groups may also distribute
  19.    working documents as Internet Drafts.  Internet Drafts are draft
  20.    documents valid for a maximum of six months.  Internet Drafts may be
  21.    updated, replaced, or obsoleted by other documents at any time.  It
  22.    is not appropriate to use Internet Drafts as reference material or to
  23.    cite them other than as a ``working draft'' or ``work in progress.''
  24.    Please check the 1id-abstracts.txt listing contained in the
  25.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  26.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  27.    current status of any Internet Draft.
  28.  
  29.    Distribution of this memo is unlimited.
  30.  
  31. Abstract
  32.  
  33.    As required by Routing Protocol Criteria [1], this report documents
  34.    the key features of Routing over Demand Circuits on Wide Area
  35.    Networks - RIP [2] and the current implementation experience.
  36.  
  37. Acknowledgements
  38.  
  39.    I would like to thank colleagues at Spider, in particular Richard
  40.    Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP
  41.    and SAP implementations.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Meyer                                                           [Page 1]
  55.  
  56. Internet Draft  Routing over Demand Circuits - Analysis         Jun 1993
  57.  
  58.  
  59. 1. Protocol Documents
  60.  
  61.    "Routing over Demand Circuits on Wide Area Networks - RIP" [2]
  62.    suggests an enhancement to the "Routing Internet Protocol" (RIP) [3]
  63.    and "RIP-2" [4] to allow them to run more cost-effectively on Wide
  64.    Area Networks (WANs).
  65.  
  66. 2. Key Features
  67.  
  68.    The proposal shares the same basic algorithms as RIP or RIP-2 when
  69.    running on LANs or fixed point-to-point links; Packet formats,
  70.    broadcast frequency, triggered update operation and  database
  71.    timeouts are all unmodified.
  72.  
  73.    The new features operate on WANs which use switched circuits on
  74.    demand to achieve intermittent connectivity.  Instead of using
  75.    periodic 'broadcasts', information is only sent as triggered updates.
  76.    The proposal makes use of features of the underlying connection
  77.    oriented service to provide feedback on connectivity.
  78.  
  79. 2.1 Triggered Updates
  80.  
  81.    Updates are only sent on the WAN when an event changes the routing
  82.    database.  Each update is retransmitted until acknowledged.
  83.    Information received in an update is not timed out.
  84.  
  85.    The packet format of a RIP response is modified (with a different
  86.    unique command field) to include sequence and fragment number
  87.    information.  An acknowledgement packet is also defined.
  88.  
  89. 2.2 Circuit Manager
  90.  
  91.    The circuit manager running below the IP network layer is responsible
  92.    for establishing a circuit to the next hop router whenever there is
  93.    data (or a routing update) to transfer.  After a period of inactivity
  94.    the circuit will be closed by the circuit manager.
  95.  
  96.    If the circuit manager fails to make a connection a circuit down
  97.    indication is sent to the routing application.  The circuit manager
  98.    will then attempt at (increasing) intervals to establish a
  99.    connection.   When successful a circuit up indication is sent to the
  100.    routing application.
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Meyer                                                           [Page 2]
  111.  
  112. Internet Draft  Routing over Demand Circuits - Analysis         Jun 1993
  113.  
  114.  
  115. 2.3 Presumption of Reachability
  116.  
  117.    In a stable network there is no requirement to propagate routing
  118.    information on a circuit, so if no routing information is (being)
  119.    received on a circuit it is assumed that:
  120.  
  121.    o  The most recently received information is accurate.
  122.  
  123.    o  The intervening path is operational (although there may be no
  124.       current connection).
  125.  
  126.    If the circuit manager determines that the intervening path is NOT
  127.    operational routing information previously received on that circuit
  128.    is timed out.  It is worth stressing that it can be ANY routed
  129.    datagram which triggers the event.
  130.  
  131.    When the circuit manager re-establishes a connection, the application
  132.    exchanges full routing information with its peer.
  133.  
  134. 2.4 Routing Information Flow Control
  135.  
  136.    If the circuit manager reports a circuit as down, the routing appli-
  137.    cation is flow controlled from sending further information on the
  138.    circuit.
  139.  
  140.    To prevent transmit queue overflow and also to avoid 'predictable'
  141.    circuit down messages, the routing application can also optionally
  142.    limit the rate of sending routing messages to an interface.
  143.  
  144. 3. Implementations
  145.  
  146.    At this stage there is only believed to be one implementation.
  147.  
  148.    The Spider Systems' implementation supports all the features outlined
  149.    for IP RIP-1, IPX RIP and IPX SAP.  RIP-2 is not currently supported.
  150.    It has been tested against itself on X.25 and ISDN WANs.  It has also
  151.    been tested in operation with various router and host RIP-1, IPX RIP
  152.    and IPX SAP implementations on Ethernet LANs.
  153.  
  154. 4. Security Considerations
  155.  
  156.    Security is provided through authentication of the logical and physi-
  157.    cal address of the sender of the routing update.  Incoming call
  158.    requests are matched by the circuit manager against a list of physi-
  159.    cal addresses (used to make outgoing calls).  The routing application
  160.    makes a further check against the logical address of an incoming
  161.    update.
  162.  
  163.  
  164.  
  165.  
  166. Meyer                                                           [Page 3]
  167.  
  168. Internet Draft  Routing over Demand Circuits - Analysis         Jun 1993
  169.  
  170.  
  171.    Additional security can be provided by RIP-2 authentication [2] where
  172.    appropriate.
  173.  
  174. References
  175.  
  176.  
  177.    [1]  Hinden, R., "Internet Engineering Task Force Internet Routing
  178.         Protocol Standardization Criteria", RFC 1264, Bolt Beranek and
  179.         Newman, Inc, October 1991.
  180.  
  181.    [2]  Meyer. G.M., "Routing over Demand Circuits on Wide Area Networks
  182.         - RIP", Internet Draft "draft-meyer-demandrouting-01.txt",
  183.         Spider Systems, May 1991.
  184.  
  185.    [3]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
  186.         University, June 1988.
  187.  
  188.    [4]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
  189.         RFC 1388 Draft, Xylogics, 1992.
  190.  
  191. Author's  Address:
  192.  
  193.    Gerry Meyer
  194.    Spider Systems
  195.    Stanwell Street
  196.    Edinburgh EH6 5NG
  197.    Scotland, UK
  198.  
  199.    Phone: (UK) 31 554 9424
  200.    Fax:   (UK) 31 554 0649
  201.    Email: gerry@spider.co.uk
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Meyer                                                           [Page 4]
  223.  
  224.